What if user wants to init() colorama with autoreset=True while the stream has already been wrapped by a library with autoreset=False?
It looks like this implementation is going to prevent him from getting the desired result, right?

The hanging and huge delays while wrapping the same stream is a big issue indeed, it has been reported in #196 and I opened #198 to fix it.

Adding a safeguard arround multiple wrapping could be useful though to avoid RecursionError when init() is called thousands of times. However, if that happens, I think the user is doing something wrong.

Hi Delgan!
Thank you for your quick response. You're right, I missed that case. There is even unit test that verifies the behaviour that you've mentioned.

This also brings another thought: if there is a test case that does a doubled initialisation, it may cause people to think that colorama may be initialised several times and the only effect should be the stream wrapper settings update. That leads to a conclusion: why calling init() thousands of times is something wrong, if a similar behaviour is presented inside unit tests?

That's also the reason why I've changed that unit test in the initial version, to avoid any further confusion in the usage of init() function.

Let me add a short story that shows how you may get into troubles with several init() calls:

1. A developer tries to make a fancy logging module, that formats each log message in a way that errors are printed in red, warnings in yellow, and infos in white.
2. Everything works perfectly on Linux, but one day he tries to use it under Windows. A well-proven solution for that is to use a mature project like colorama. The init() is called inside logger constructor, as that seems to be a logical place for it.
3. After couple of months, the module starts to be used as a primary logging method.
4. While project evolves, more instances of fancy logger are created, and one day - BOOM, everything starts to slow down, and finally - the software reaches RecursionError.

Of course, you may say - if someone does module-level initialisation at non-singleton object level, he has a bug in his code, but I bet that pasting one of unit tests would give you an approval in most of code reviews 🙂

Yeah, you are probably right and your example is pretty convincible. 🙂

The fact that several people have reported encountering RecursionError problems is also a hint that something could be improved.

I can't think of any downside with your suggested change, but it should be interesting to know why it has not been implemented like this in the first time and why nested wrapping had been chosen instead.

The only surprising effect would be in this case:

1. Someone call init()
2. Someone wrap or replace sys.stderr with another stream-object
3. Someone call init() again

Then, the resulting sys.stderr would not be the one expected, but I don't know if such situation happens that often.

Hey. FYI, Yesterday I created a PR to test releases before we push them to PyPI. When that is merged, I'll be more confident about resuming merges and releases. I'll try to look at this PR soon. Thank you for creating it!

This PR dupes fixes in #236 and #262 (although this one predates those)